feat: add extraPortMappings support to ClusterSpec - #16

Follow-ups to praxis-proxy#13, found by a review pass after it merged. Each one is a
defect with an observable consequence; nothing here changes what the
benchmark measures.

Broken or dead:

- The `ai-extended` scenario referenced two config files that do not
  exist, so selecting it aborted on the first `kubectl create` under
  `set -euo pipefail`, and report.sh had no branch for its result prefix.
- The per-run `kubectl top pod` snapshot always failed into `|| true`,
  because no stack installs metrics-server and KIND does not ship it. It
  wrote nine empty `*-resources.txt` files per 3x3 run; the dashboards
  already plot CPU and memory from cAdvisor.
- `export BRANCH=$(...)` in report.sh masked the command's exit status
  (SC2155), which shellcheck never saw because the lint target only
  covered `hack/` and `.hooks/`.
- Two comments described a `[patch.crates-io]` table that the 0.5.4 bump
  had already removed.
- The prerequisites told you to install forge from a feature branch.
  praxis-proxy/forge#16 has merged, so `extraPortMappings` is in main.

Observability of the trace pipeline:

- A `memory_limiter` now runs first in the collector pipeline. The
  container is capped at 512Mi and nothing shed load before it, so under
  exporter backpressure the queue grew until the kernel killed the
  collector and every buffered span went with it. Refusals land in
  `otelcol_processor_refused_spans`, charted beside the export failures.
- The Span Export Failures panel filters to `exporter="otlp/tempo"`. The
  pipeline also has a `debug` exporter, so the unfiltered sum counted
  every span twice and a debug-exporter hiccup read as a Tempo failure.

Supply chain and build:

- praxis-ai is pinned to the commit tagged v0.3.0 rather than to the tag,
  which is what deny.toml's comment already claimed. A tag can be
  force-moved upstream; a commit cannot.
- `make container FEATURES=otel` plumbs the build-arg through, so the
  repo's own tooling can build the image the demo READMEs ask for instead
  of the hand-rolled `docker build` lines they carry today.
- A cargo git cache mount alongside the registry one: the ai dependency is
  a git source and was re-cloned on every image build.

Signed-off-by: Ladislav Smola <lsmola@redhat.com>

Follow-ups to praxis-proxy#16, found by review after it merged.

The host-binding registry compares bind addresses as `IpAddr`, which
distinguishes an address by variant. `::ffff:127.0.0.1` and `127.0.0.1`
name the same interface to the container runtime but never compared
equal, so a cluster mapping and a service port using the two notations
for one interface passed validation and then collided at `forge up` with
the opaque "port is already allocated" the registry exists to prevent.
`canonical_ip` collapses the mapped form before comparison. Two tests
cover it: the mapped pair now conflicts, and `::1` against `127.0.0.1`
still passes, because those are genuinely two addresses.

Also:

- The bind-address parse check was written twice, once for clusters and
  once for services, differing only in the error prefix. Folded into one
  `check_bind_address` taking a `PortOwner`, which already renders both
  prefixes.
- `PortMapping::protocol` was documented as "tcp or udp". The field is
  shared by two validators that accept different values: cluster
  mappings take tcp, udp or sctp case-insensitively, matching KIND, and
  service ports take tcp only. The doc now says so, and the two protocol
  checks explain why they differ.
- `generate_kind_config` claimed KIND only supports port mappings on
  control-plane nodes. KIND accepts the field on any node; one node is
  enough because kube-proxy makes a NodePort reachable through every
  node, and publishing the same host port from several would collide.

Signed-off-by: Ladislav Smola <lsmola@redhat.com>